Data assessment and visualization platform for use in a network environment including computing devices

ABSTRACT

Generally described, one or more aspects of the present application relate to enabling determination of a predicted effect of a target action on sensor data generated on a computing device. More specifically, the present disclosure provides a system that can analyze sensor data generated on a computing device before and after a target action, generate analytics data indicating the effect of the target action on the sensor data generated on the computing device, and store the analytics data in association with the one or more characteristics associated with the computing device one or more characteristics of the target action. Subsequently, the system can analyze a given set of characteristics associated with a different computing device and characteristics and sensor data generated on said different computing device, and output, based on the previously generated analytics data, an indication of the predicted effect of a given action or set of actions on the sensor data to be generated on said different computing device.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

This application is a continuation-in-part (CIP) application of U.S.patent application Ser. No. 17/303,830, filed on Jun. 8, 2021, whichclaims priority to U.S. Provisional Application No. 63/036,299, filed onJun. 8, 2020, the disclosure of which is incorporated herein byreference in its entirety for all purposes. Any and all applications forwhich a foreign or domestic priority claim is identified in theApplication Data Sheet as filed with the present application are herebyincorporated herein by reference in their entirety under 37 CFR 1.57 forall purposes.

TECHNICAL FIELD

This disclosure relates to the field of facilitating generation,transmission, and presentation of analytics data across computingdevices and activity tracking devices within in a network environment.

BACKGROUND

Patient reported outcome measures (PROM's) are often used to assess thehealth status of a surgical patient. For example, a PROM survey mayinclude a number of specific questions for the patient to answer beforeand after the surgery. The answers to these questions may then be usedto determine a numeric score, by which relative benefit can then bedetermined. However, these answers are inherently subjective and oftenmeasured in large chunks (e.g., weeks if not months or years),accurately predicting the efficacy of the surgery or the patientrecovery pattern solely based on these answers may be difficult. Thus,more effective, granular, and objective techniques for determining theefficacy of medical interventions and predicted pattern ofpost-intervention recovery are desired.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a schematic diagram of a network environment in which amedical intervention analytics system is used to implement a dataanalysis service and a report generation service in accordance withaspects of the present disclosure.

FIG. 2 depicts a block diagram illustrating an example work flow ofprocessing patient activity data, in accordance with aspects of thepresent disclosure.

FIG. 3 is a flowchart of an example process for performing a post-opanalysis of patient data, in accordance with aspects of the presentdisclosure.

FIG. 4 depicts graphs illustrating the activity data, in accordance withaspects of the present disclosure.

FIG. 5 depicts graphs illustrating the distribution of activity data, inaccordance with aspects of the present disclosure.

FIG. 6 depicts graphs illustrating the mean activity levels with errorbars, in accordance with aspects of the present disclosure.

FIG. 7 depicts a graph illustrating the times of increased and decreasedactivity levels, in accordance with aspects of the present disclosure.

FIG. 8 depicts heat maps illustrating the levels of activity withoverlaid arrows, in accordance with aspects of the present disclosure.

FIG. 9 depicts graphs illustrating the levels of steps and step sizes,in accordance with aspects of the present disclosure.

FIG. 10 depicts graphs illustrating the levels of distances and flights,in accordance with aspects of the present disclosure.

FIG. 11 depicts graphs illustrating the pre-op and post-op levels ofsteps, distances, and flights for each day of the week, weekdays,weekend days, and all days, in accordance with aspects of the presentdisclosure.

FIG. 12 depicts graphs illustrating the pre-op and post-op levels ofsteps in different types of scenarios including visual indications ofthe identified temporal windows (epochs), in accordance with aspects ofthe present disclosure.

FIG. 13 depicts graphs illustrating comparisons of pre-op and post-opsteps, in accordance with aspects of the present disclosure.

FIG. 14 depicts a graph illustrating a comparison of the skewness ofpre-op and post-op distribution of steps, in accordance with aspects ofthe present disclosure.

FIG. 15 depicts a block diagram illustrating an example work flow ofassisting a decision of whether to undergo a surgical intervention, inaccordance with aspects of the present disclosure.

FIG. 16 is a flowchart of an example process for performing a pre-opanalysis of patient data, in accordance with aspects of the presentdisclosure.

FIG. 17 is a flowchart of an example process for outputting visuallydistinguished temporal windows, in accordance with aspects of thepresent disclosure.

FIG. 18 is a flowchart of an example process for identifying temporalwindows based on patient activity data, in accordance with aspects ofthe present disclosure.

FIG. 19 depicts a graph illustrating a patient's activity level overtime, in accordance with aspects of the present disclosure.

FIG. 20 depicts another graph illustrating a patient's activity levelover time, in accordance with aspects of the present disclosure.

FIG. 21 depicts another graph illustrating a patient's activity levelover time, in accordance with aspects of the present disclosure.

FIG. 22 depicts a general architecture of a computing system usable toimplement one or more components described herein in accordance withaspects of the present disclosure.

DETAILED DESCRIPTION Introduction

Surgeons are faced with the challenge of determining the optimal surgeryfor a given pathology on a daily basis. This is perhaps exemplified byspinal surgery as an example. As spinal surgery has evolved, the surgeonhas access to a wide array of treatment options. Surgicaldecision-making, therefore, becomes an increasingly complex process,where a surgeon must parse the existing literature with each patient'sunique pre-existing pathology, age, functional status and lifestyle. Thecomplexity of this decision is reflected in studies which demonstrate7-fold differences in the rates of lumbar laminectomies and 10-folddifferences in the rate of lumbar fusions between surgical practicepatterns. Perhaps even more importantly, the surgeon must decide whichscientific evidence and literature to use for guidance. This is not tosay that a surgeon needs to choose between a randomized controlled trialvs. a case report to determine optimal surgical approach—the hierarchyof evidence-based medicine is quite clear. Rather, the surgeon maydecide how to use the existing literature to best gauge benefit vs.risks for each individual patient's overall clinical picture. This lackof clinical certainty arises in part from the fact that many pathologiesof the spine have several different documented approaches—each of whichis being reported as successful in one or more dimensions.

There is a large body of research regarding fusion and failure ratesalong with adequacy of decompression for various surgical procedures. Inmany cases, this type of research is driven by radiologic findings whichhelp the surgeon to understand how the human body and bone will react tovarious approaches. There is likewise a large quantity of literatureexploring the biomechanical advantages and disadvantages of varioussurgical procedures. This body of literature relies largely uponcadaveric or finite element analysis. However, surgeons realize that thepatient's clinical response is perhaps the most important factor toconsider. Indeed, even if the literature demonstrates the biomechanicaland structural improvements after a given surgery, these findings lackrelevance if they do not result in a real and meaningful improvement inthe patient's quality of life.

These same issues arise in surgical decision-making in nearly everysub-specialty, including cardiac, orthopedic, bariatric, and oncologicsurgery, to name a few. While the technical aspects of thesub-specialties differ, in all surgical fields the physician strugglesto apply relevant outcomes-driven research to modify practice patternsat the individual patient and population levels.

To date, measuring the success of the surgery has relied on PatientReported Outcome Measures (PROM's). The vast majority of PROM's aresurveys which ask the patient to answer a number of specific questionsbefore and after the surgery. The answers to these questions are thenused to determine a numeric score, by which relative benefit can then bedetermined. There are a number of different PROM surveys in existence,and for spine the most commonly utilized include the Oswestry DisabilityIndex (ODI), visual analog scale (VAS) back pain and leg pain, and theNeck Disability Index (NDI), just to name a few. More general PROM's canbe applied across multiple arenas of human function, such as the ShortForm (SF)-36 health survey.

While these PROM surveys do represent an important conceptual leapforward, there are a number of problems with relying solely upon them togauge benefit. First is their inherently subjective nature. The factthat a patient feels or states that they are more functional does notnecessarily mean that it is so. These surveys are undoubtedly subject toa number of biases which the patients consciously or unconsciouslyincorporate into their responses.

Additionally, there seems to be a broad lack of standardization in termsof which PROM to use. A retrospective review of orthopedic spinejournals noted 206 different PROM's used across 1,079 studies. Perhapsequally as importantly, there was a notable lack of consistency in termsof methodology and score calculation even amongst the most commonly usedPROM's. This highlights yet another issue with PROM's—namely, that ifthese metrics are not standardized or consistently calculated, theirutility in demonstrating relative value and treatment efficacy islimited. How should we standardize them? Which metrics are mosteffective? And over what time-frame should they be used to predictoutcomes? One notable study found that 3 month PROM data did notreliably predict 12 month outcomes on an individual patient level.Should the surgeon then continue to collect PROM data for 1 year?Perhaps 2 years? The answers to these questions remain murky at best.

With the advent of modern technology, we now have the means toaccurately capture daily activity on both a retrospective andprospective basis. For example, a user's smartphone may be equipped withnumerous sensors (e.g., accelerometer, gyroscope, compass, etc.) thatcan generate sensor data, and the smartphone may, with the help of oneor more mobile applications installed thereon, calculate or estimatevarious indicators of user mobility such as step count, step size,distance traveled, flights of stairs climbed, calorie count, standingminutes, active minutes, etc. This activity data will be free of userbias, and will provide a true measure of functional status. Byprocessing and analyzing the activity data that has already beencaptured and stored by multitude of personal mobile devices (e.g.,smartphones, smartwatches, fitness trackers, etc.), the techniques ofthe present disclosure can apply a consistent and objective computeralgorithm, provide an excellent tool for measuring human function. Byanalyzing these activity of patients, the present disclosure provides anobjective method of measuring pre-op and post-op functional statuses ofthe patients.

For example, utilizing existing health data stored on smartphones, it ispossible to capture information on thousands of patients who havealready undergone surgeries retrospectively. By capturing a much largernumber of patients, the results are powered to detect objectiveimprovement or worsening of patient's or population's functional statusafter undergoing surgery. This analyzed data and metric will be valuablein helping to gauge not only the impact of various types of medicalinterventions, but also the timing of this impact, and its relationshipto patient baseline characteristics. This objective measurement ofsurgical intervention can be the key to developing value-basedreimbursement model for Medicare/Medicaid/private insurance companies.Under the current fee-for-service model, the reimbursements are basednot on the patient outcome but rather on the types of procedures (CPT)and the diagnosis codes (ICD-10). Objective, reliable, consistent andaccurate objective real-time activity levels of pre- and post-surgicalpatients will allow this paradigm shift in the business of medical carein the United States.

The present disclosure includes a method of safely, securely, andefficiently collecting large quantities of post-processed activity datacollected and stored within user computing devices such as smartphones.For instance, a smartphone may have a built-in three-axis accelerometeras well as three-axis gyroscope, which are usable to calculate and trackthe number of steps based on speed and movement of the smartphone. Bycombining demographics data such as age, gender, height and weight ofthe user, the triaxial accelerometer can be used to estimate energyexpenditures during physical activities by the pre-defined empiricalrelationship between accelerometer and energy expenditure data measuredby a calorimeter. While this data is potentially useful to the typicalconsumer, it remains only loosely relevant from the perspective ofmonitoring health status. In its current form, the data that ispresented appears largely to be of interest to those involved in generalfitness or athletic endeavors, and thus falls short of being useable asa health metric or outcome measure. A raw number of steps before andafter the date of surgery will be meaningless unless those numbers arecompared to a large cohort of patients who underwent similar surgery.For instance, if Ms. Jones underwent one-level lumbar microdiscectomyand her pre-operative steps per day went from 4000 to 6000 at one-yearpost-op, what does that mean? Should she be at 8000 steps per day atone-year post-op to qualify her activity level as “good” outcome? How doyou define baseline pre-op steps per day? How do you make these activitylevels clinically meaningful?

The aforementioned challenges and questions, among others, are addressedin some embodiments by the disclosed techniques for processing patientdata, determining a predicted surgical efficacy (e.g., how the physicalconditions such as the mobility of the patient might improve) of aproposed surgical intervention (e.g., spine surgery), and determining apredicted pattern of post-operative recovery (e.g., the number of stepsthat the patient can expect to take 15 days, 30 days, or 90 days fromthe surgery date) for the patient, among others, are described herein.More specifically, the present disclosure provides a system that cananalyze the patient data of a plurality of patients data, generateanalytics data indicating the post-operative recovery of the pluralityof patients, and store the analytics data in association with thebiological traits of the patients and the types of surgicalinterventions that the patients underwent. Subsequently, the system cananalyze the patient traits and activity data of a new patient, andoutput, based on the previously generated analytics data, a predictionof how efficacious a given surgical intervention might be for thatpatient and/or how the patient might recover from the given surgicalintervention.

As will be appreciated by one of skill in the art in light of thepresent disclosure, the embodiments disclosed herein improve the abilityof computing systems, such as data analysis systems, data processingsystems, machine learning systems, etc., to provide more efficient andeffective data analysis techniques. By utilizing the pre-op and post-ophealth data or sensor data generated based on the movement of usercomputing devices, generating visual comparisons and predictions, andutilizing and updating machine learning algorithms usable to generatesuch visual comparisons and predictions, the medical interventionanalytics system of the present disclosure can address the deficienciesdescribed above.

These and other aspects of the disclosure will now be described withregard to certain examples and embodiments, which are intended toillustrate but not limit the disclosure. Although the examples andembodiments described herein will focus, for the purpose ofillustration, on specific calculations and algorithms, one of skill inthe art will appreciate the examples are illustrate only, and are notintended to be limiting.

Technical Advantages

Temporally granular data—Traditional metrics are typically assessed atpredetermined time points. This is not only onerous, but also missesdata between the sampling times. Existing PROM's are sampled with gapsin the range of weeks, to months, to years. The techniques describedherein (also referred to herein as Objective Realtime BioInformationTracker, “ORBIT” in some embodiments) allow the user to samplepotentially any specific time point for comparison, and also allows theanalysis to be from aggregated time points to further overcome samplingerrors. This ability to continuously monitor the progress is criticalsince it can allow for early detection of either improvement orworsening before the patient comes back to the clinic. PROM is onlycollected when the patient fills out a survey, whereas the techniquesfor analyzing the patient data described herein can be applied on areal-time basis and updated as soon as the physical activity data isimported from the patient's smartphones (e.g., all activity data can beimported initially, and additional activity data can be importedperiodically (e.g., every 2 weeks) or on demand (e.g., whenever the userwishes to generate or visualize updated analytics data, which may beindicated by the user activating a user interface element presented onthe user computing device 102)).

Automatic collection—The techniques described herein may not need torely on any specific patient or provider action as data can be collectedpassively. This may overcome patient compliance issues and also avoidthe possibility of inadvertently missing the opportunity to sample data.

Prospective data analytics—The software application allows for efficientprospective data collection and analysis. For the patient as a user thiscould represent a real-time feedback mechanism by which to modify andimprove behavior. For instance, if there is a decline in ORBIT, thiswould trigger an alert to the patient and the treating physician, andthey can decide whether a clinic visit is needed. For the analyst thisallows for early detection of any variances which could provide usefulindicators of patient performance after an intervention.

Retrospective data analytics—Using a methodology analogous to theprospective data collection and analysis, data can also be retrievedretrospectively. This is a powerful tool leveraging the smartphone andany associated cloud-based data storage systems in use. Data abstractedgoing back years for any given individual or patient can be analyzed inaggregate. For example, one of the differentiating elements of the dataanalysis techniques described herein is the ability for the user toabstract a meaningful health outcome metric from previously stored data.Unlike PROM, which requires a patient to fill out a survey in order tocome up with the score, ORBIT can be calculated based on physicalactivity data from the date of purchase of a smartphone. Most users willhave interest in evaluating a health outcome measure at time pointsbefore intent or action was undertaken. This is particularly valuable inhealth outcomes research, efficacy studies of interventions, andevaluation of a previous health events in a patient's life. ORBIT allowsdetermination of a baseline and any follow-up time point in the past tobe objectively measured. This allows the user of the softwareapplication to ascertain objectively the health metric at potentiallyany previous time point that the user has had smartphone technology.Thus, users who have already undergone previous interventions can bestudied in a granular and objective manner. This presents a utility tothe patient as well as stakeholders in any medical intervention asnearly all previous health metrics required prospective collection of abaseline metric at a minimum or some element of non-standardized datainterpolation.

Machine-based learning—Existing PROM's remain fixed in their manner ofdata query. Because of the elemental nature as well as size of thedatasets collected and analyzed, ORBIT can leverage machine-basedlearning to adapt and increase its relevance as a health measure.Machine learning algorithms may be generated and continually trainedusing relevant independent variable to predict pre- and post-surgicalactivity level.

Analysis across non-linear dynamic ranges of measurement—The numericalsimplicity of existing PROM's are appealing but improbably reflect thetrue nature of a biological system. ORBIT allows non-linear measurementof patient performance. While the datasets are composed of linearmeasurements, the ability to post-process data allows for the ORBITmetric to detect and convey health information in the most importantdynamic ranges. In particular, sensitivity to changes at the low end ofhuman performance are most likely to carry the greatest medicalrelevance.

These and other aspects of the disclosure will now be described withregard to certain examples and embodiments, which are intended toillustrate but not limit the disclosure. Although the examples andembodiments described herein will focus, for the purpose ofillustration, on specific calculations and algorithms, one of skill inthe art will appreciate the examples are illustrate only, and are notintended to be limiting.

Overview of Example Computing Environment for Medical InterventionAnalytics System

The illustrative network environment 100 shown in FIG. 1 includes amedical intervention analytics system 106 according to one embodiment.The medical intervention analytics system 106 enables a user (e.g., apatient, a medical professional, a researcher, a data scientist, amedical intervention evaluator, etc.) to utilize the data analysisservice and the report generation service provided via the medicalintervention analytics system 106. The user may input patient data(e.g., age, gender, ethnicity, height, weight, co-morbidities, etc.)and/or answer a set of questions via a user interface presented on theuser computing device 102, along with information relating to thesurgery that has already been performed or to be performed (e.g.,surgery date, surgery type, etc.), which may be transmitted to themedical intervention analytics system 106 (or to a data repositoryaccessible by the medical intervention analytics system 106). Inresponse, the medical intervention analytics system 106 may output areport based on the provided information. The details of the dataanalysis and the report generation are described in greater detailbelow.

By way of illustration, various example user computing devices 102 areshown in communication with the medical intervention analytics system106 via network 104. The user computing devices 102 can be any computingdevice such as a desktop, a laptop, a mobile phone (or smartphone), atablet, a kiosk, a television, a wristwatch (including a smartwatch), afitness tracker, a wireless device, a media player, one or moreprocessor devices, integrated circuit components for inclusion incomputing devices, and the like.

The network 104 over which the user computing devices 102 can access themedical intervention analytics system 106 may be any wired network,wireless network, or combination thereof. In addition, the network 104may be a personal area network, local area network, wide area network,over-the-air broadcast network (for radio or television, for example),cable network, satellite network, cellular telephone network, orcombination thereof. For example, the network 104 may be a publiclyaccessible network of linked networks, possibly operated by variousdistinct parties, such as the Internet. In some embodiments, the network104 may be a private or semi-private network, such as a corporate oruniversity intranet. The network 104 may include one or more wirelessnetworks, such as a Global System for Mobile Communications (GSM)network, a Code Division Multiple Access (CDMA) network, a Long TermEvolution (LTE) network, or any other type of wireless network. Thenetwork 104 can use protocols and components for communicating via theInternet or any of the other aforementioned types of networks.

In the depicted embodiment, the medical intervention analytics system106 includes servers 120, which can communicate with the user computingdevices 102 over the network 104 and provide access to various servicesof the medical intervention analytics system 106. In the example of FIG.1, the services provided by the medical intervention analytics system106 include a data analysis service 130 and a report generation service150. In some embodiments, these services can be implemented as softwarecomponents executing in physical computer hardware on the servers 120 orin separate computing devices. The term “service,” as used herein and inaddition to its ordinary meaning, may in some embodiments also refer tothe underlying physical hardware implementing the operations describedherein.

The medical intervention analytics system 106 may provide userinterfaces (and/or instructions therefor) for display upon the usercomputing devices 102, for example, via a navigation and/or browsinginterface such as a browser or application installed on the usercomputing devices 102, and the users on the user computing devices 102may utilize the various services provided by the medical interventionanalytics system 106 such as the data analysis service 130 and thereport generation service 150 via the user interfaces.

The data analysis service 130 can access data repository 140 and/or datasources 160 to collect and/or generate certain patient data, analyticsdata, machine learning data, or any portions thereof to perform the dataanalyses described herein. The report generation service 150 can accessthe analytics data from the data repository 140 and generate reportsand/or user interfaces to convey various visual indicators, predictions,and results of the patient and medical intervention analytics describedherein.

In some embodiments, data generated by the user computing devices 102may be sent directly to the system 106 (e.g., and stored in the datarepository 140) or to the data sources 160 (e.g., by the mobileapplication installed on the user computing devices 102) for retrievalby the data analysis service 130 (for use in the analytics performed bythe data analysis service 130 and/or for subsequent storing in the datarepository 140). Although the data sources 160 are shown outside themedical intervention analytics system 106, in some embodiments, some orall of the data sources 160 may be implemented within the medicalintervention analytics system 106.

The data repository 140 may store patient data 142, analytics data 144,and machine learning data 146. The patient data 142 may includebiological and other traits associated with patients (e.g., age, gender,ethnicity, height, weight, co-morbidities, etc.), activity dataassociated with patients (e.g., raw activity or sensor data and/orprocessed activity data such as step count, step size, number of flightsclimbed, distance traveled, calorie count, standing minutes, activeminutes, gait asymmetry, etc.), and surgery data associated withpatients (e.g., details relating to a medical intervention that apatient has undergone or will be undergoing, such as medicalpractitioner, medical intervention date, medical device used, medicaldevice manufacturer, medical intervention duration, level ofinvasiveness, medical intervention time of day, etc.). In someembodiments, the patient data 142 may be provided by multiple users(e.g., by a user computing device 102 of the patient as well as a usercomputing device 102 of the physician/evaluator/researcher/etc.) andcross-checked and/or de-duplicated.

The analytics data 144 may include, for example, (i) processed versionsof the patient data such as averages, sums, aggregates, subsets,z-scores, means, standard deviations, graphs, charts, etc., (ii) datapoints of interest such as acute decline, post-op recovery, etc., and(iii) temporal windows (also referred to herein as epochs) identifiedusing the patient data 142 and/or other analytics data, (iv) medicalintervention efficacy scores described herein, (v) patient improvementindices (e.g., how this particular patient is doing pre-op and/orpost-op compared to other similarly situated patients, based on thepatient data), (v) predictions of medical intervention efficacy scoresand/or recovery patterns (e.g., graphs, tables, or other indicators ofhow a patient might recover), to name a few examples.

The machine learning data 146 may include one or more machine learningmodels or algorithms generated and/or trained by the medicalintervention analytics system 106. One or more of these predictionmodels may be used to determine an expected value or occurrence based ona set of inputs. For example, a prediction model can be used to predicta patient's future activity levels based on one or more inputs to theprediction model, such as, for example, patient data described herein,medical intervention data, past activity data of the patient, andpreviously analyzed patient data, medical intervention data, andactivity data of other users. A number of different types of algorithmsmay be used by the medical intervention analytics system 106. Forexample, certain embodiments herein may use a logistical regressionalgorithm. However, other algorithms are possible, such as a linearregression algorithm, a discrete choice algorithm, or a generalizedlinear algorithm.

The medical intervention analytics system 106 is depicted in FIG. 1 asoperating in a distributed computing environment including severalcomputer systems that are interconnected using one or more computernetworks. The medical intervention analytics system 106 could alsooperate within a computing environment having a fewer or greater numberof devices than are illustrated in FIG. 1. Thus, the depiction ofmedical intervention analytics system 106 in FIG. 1 should be taken asillustrative and not limiting to the present disclosure. For example,the medical intervention analytics system 106 or various constituentsthereof could implement various Web services components, hosted or“cloud” computing environments, and/or peer-to-peer networkconfigurations to implement at least a portion of the processesdescribed herein.

Further, the medical intervention analytics system 106 and itscomponents may be implemented in hardware and/or software and may, forexample, include one or more physical or virtual servers implemented onphysical computer hardware configured to execute computer executableinstructions for implementing the various features described herein. Theone or more servers may be geographically dispersed or geographicallyco-located, for example, in one or more data centers. In someembodiments, one or more of the components shown in FIG. 1 may beimplemented on one or more virtual servers or virtual machines.

Moreover, the processing of the various components or services of themedical intervention analytics system 106 can be distributed acrossmultiple machines, networks, or other computing resources. The variouscomponents or services of the medical intervention analytics system 106can also be implemented in one or more virtual machines or hostedcomputing environment (for example, “cloud”) resources, rather than indedicated servers. Likewise, the data repositories shown can representlocal and/or remote, physical and/or logical data storage, including,for example, storage area networks or other distributed storage systems.In some embodiments, the connections between the components or servicesshown represent possible paths of data flow, rather than actualconnections between hardware. Executable code modules that implementvarious functionalities of the medical intervention analytics system 106can be stored in the memories of the servers 120 and/or on other typesof non-transitory computer-readable storage media. While some examplesof possible connections are shown, any subset of the components showncan communicate with any other subset of components in variousimplementations.

Processing Patient Activity Data

FIG. 2 depicts an illustrative data flow 200 for processing patientactivity data in accordance with aspects of the present disclosure. Asshown in FIG. 2, the data flow 200 may include (i) raw accelerometerdata, (ii) de-identified and re-assigned unique identifiers, (iii)machine learning algorithms, (iv) estimated steps, distances, flights,and energy expenditure data, (v) multivariable linear regression models,and (vi) supervised machine learning algorithms. For example, the system106 may have the capacity to automatically deidentify the user'spersonal information and assign a unique identifier to the importeddataset. Once the user has consented to the data sharing agreement, themobile application installed on the user's computing device maycontinually extract and populate the database on the cloud on-goingbasis. Raw accelerometer data may then be processed to calculatephysical activity parameters such as steps taken, distance travelled,flights climbed, standing minutes, and energy expenditure using anexisting algorithm. Once physical function data has been generated foran individual user, these data points may be added to the library ofdatabase that contains previously collected data.

Once the steps, distance, flights, calorie, and standing minute data hasbeen generated for each patient, these data are organized into daily,weekly, and monthly averages. For each parameter (e.g., average stepsper day, distance per day, active calorie burned, flights climbed andstanding minute), outliers (e.g., more than 2 standard deviations awayfrom the mean) may be removed, and a graph may be generated. Once theparameters are collected for each patient, these are displayed in adashboard format where the time to achieve or exceed the baselineactivity level are displayed. In addition, the graphs are generated foreach parameter as well.

Using the described steps below, an ORBIT score may be calculated foreach patient. Multivariable linear regression may be used to generate amodel based on the existing independent variables such as age, sex,ethnicity, baseline medical co-morbidities, type of surgery, level ofsurgery, pre-operative baseline physical activity, post-operativephysical activity levels and others. Multivariable linear regressionmodel will be updated daily. Supervised learning for machine learningalgorithm may be performed by inputting independent variables (age,gender, body mass index, surgery type, baseline physical function, etc.)to predict a user's physical function after surgery (e.g., steps,distance, energy expenditure, flight climbed and standing time).

In some embodiments, based on five physical function metrics (steps perday, distance per day, active calorie burned, flights climbed andstanding minute), an ORBIT (Objective Realtime BioInformation Tracker)score can be calculated for each subject. This is a composite scoringmethod that will be validated against PROM. Pearson correlationcoefficients will be calculated between PROMs and ORBIT to see if thereis divergence or correlation between the two. Each components of theORBIT will be given a weighted score. This data will be invaluable inhelping to gauge not only the impact of various types of surgicalinterventions, but also the timing of this impact, and its relationshipto patient baseline characteristics. ORBIT takes into account of time torecovery and the amount of recovery; therefore, its score reflects howfast or slow the patient recovered and how much each physical activityparameters (steps, distance, calorie, flights climbed and standingminutes) changed after surgery. ORBIT score is calculated using existingpatient's physical data and its details are described below. ORBIT canalso be predicted using machine learning algorithm for individualpatients who has not yet gone through a surgery based on their baselinecharacteristics and their pre-operative physical activity level data.

An example of calculating the ORBIT score is described below:

Keywords:

-   Steps per day=SPD-   Distance per day=DPD-   Active Calorie Burned=ACB-   Stand Minutes=SM-   Flights Climbed=FC-   ODI=Oswestry Disability Index-   NDI=Neck Disability Index

The ORBIT score is a weighted scoring system for SPD, DPD, ACB, SM, FCand present a combined scoring to reflect:

-   Time to return to baseline SPD, DPD, ACB, SM, FC-   Grade SPD, DPD, ACB, SM, FC

The ORBIT score is a composite weighted score, taking into accountchanges in 5 domains of physical activity from their baseline to thetime of assessment. There is two dimensions, temporal and gradient, to 5main domains of physical activity measures. The ORBIT score can rangefrom −15 to 25, higher score representing more physical activity, lowerscores representing less physical activity.

Steps per day (SPD):

-   Mean baseline steps per day (1YbSPD),(9MbSPD),(6MbSPD),(3MbSPD) is    defined by the total number of steps 1 year, 9 months, 6 months, and    3 months prior to the surgery and up to a day before the surgery    divided by 365 days.    -   bSPD=total number of steps over 1 year period/365 days    -   Day of surgery will be the day 0-   SPD will be reported in mean and standard deviation included for all    patients-   SPD will be organized in weekly manner    -   W0=the week of surgery, day 0-6 then W1, W2, W3 . . . etc    -   Weekly SPD        -   W0SPD=(total number of steps in week 0)/7 days-   bSPD (365 days), W0SPD, W1SPD, W2SPD, W3SPD, W4SPD, W5SPD, W0SPD,    W12SPD, M6SPD, M9SPD, Y1SPD, Y2SPD-   Time to achieve bSPD (Temporal Component)    -   Early Recovery (ER): those who achieved or exceeded pre-op bSPD        within W12    -   Late Recovery (LR): those who achieved or exceeded pre-op bSPD        from W13 to Y2    -   No Recovery (NR): those who never achieved or exceeded pre-op        bSPD from W0 to Y2-   Grading the achievement from M6 to Y2    -   M6-Y2 SPD will be defined by the total steps from M6 to Y2/540        days        -   Severe Worsening (SW): those who are 0% to 49% of bSPD        -   Moderate Worsening (MoW): those who are 50% to 75% of bSPD        -   Mild Worsening (MW): those who are 76% to 99% of bSPD        -   Mild Recovery (MR): those who are 100% to 125% of bSPD        -   Moderate Recovery (MoR): those who are 126% to 150% of bSPD        -   Significant Recovery (SR): those who are 151% to 200% of            bSPD

Distance per day (DPD)—This is another indicator of mobility in additionto the steps per day.

-   bDPD=total distance travelled over 1 year period/365 days-   DPD will be organized in weekly manner-   Time to achieve DPD and beyond    -   Early Recovery (ER): those who achieved or exceeded pre-op bDPD        within W12    -   Late Recovery (LR): those who achieved or exceeded pre-op bDPD        from W13 to Y2    -   No Recovery (NR): those who never achieved or exceeded pre-op        bDPD from WO to Y2    -   Deterioration (D): those who experience worsening in pre-op bDPD        by Y2-   Grading the achievement from M6 to Y2    -   M6-Y2 DPD will be defined by mean DPD from M6 to Y2/540 days        -   Severe Worsening (SW): those who are 0% to 49% of bDPD        -   Moderate Worsening (MoW): those who are 50% to 75% of bDPD        -   Mild Worsening (MW): those who are 76% to 99% of bDPD        -   Mild Recovery (MR): those who are 100% to 125% of bDPD        -   Moderate Recovery (MoR): those who are 126% to 150% of bDPD        -   Significant Recovery (SR): those who are 151% to 200% of            bDPD

Active Calorie Burned (ACB)—This would be a powerful indication ofactivity level for the patients that may not be reflected necessarily inthe SPD. Similar ways to capture and report the data as SPD.

-   Mean baseline active calorie (kCal) burned (bACB) is defined by the    total active calorie burned over 1 year prior to the surgery and up    to a day before the surgery divided by 365 days.    -   bACB=total ACB (kCal) over 1 year period/365 days    -   Day of surgery will be the day 0-   ACB will be reported In mean and standard deviation included for all    patients-   ACB will be organized in weekly manner as above    -   W0=the week of surgery, day 0-6 then W1, W2, W3 . . . etc-   Time to achieve    -   Early Recovery (ER): those who achieved or exceeded bACB within        W12    -   Late Recovery (LR): those who achieved or exceeded bACB from W13        to Y2    -   No Recovery (NR): those who never achieved or exceeded bACB from        W0 to Y2-   Grading the achievement from M6 to Y2    -   M6-Y2 ACB will be defined by the total ACB from M6 to Y2/540        days        -   Severe Worsening (SW): those who are 0% to 49% of bACB        -   Moderate Worsening (MoW): those who are 50% to 75% of bACB        -   Mild Worsening (MW): those who are 76% to 99% of bACB        -   Mild Recovery (MR): those who are 100% to 125% of bACB        -   Moderate Recovery (MoR): those who are 126% to 150% of bACB        -   Significant Recover (SR): those who are 151% to 200% of bACB

Stand Minutes (SM):

-   bSM=total stand minute over 1 year period/365 days-   SM will be organized in weekly manner-   Time to achieve bSM and beyond    -   Early Recovery (ER): those who achieved or exceeded pre-op bSM        within W12    -   Late Recovery (LR): those who achieved or exceeded pre-op bSM        from W13 to Y2    -   No Recovery (NR): those who never achieved or exceeded pre-op        bSM from W0 to Y2-   Grading the achievement from M6 to Y2    -   M6-Y2 SM will be defined by mean SM from M6 to Y2/540 days        -   Severe Worsening (SW): those who are 0% to 49% of bSM        -   Moderate Worsening (MoW): those who are 50% to 75% of bSM        -   Mild Worsening (MW): those who are 76% to 99% of bSM        -   Mild Recovery (MR): those who are 100% to 125% of bSM        -   Moderate Recovery (MoR): those who are 126% to 150% of bSM        -   Significant Recovery (SR): those who are 151% to 200% of bSM

Flights Climbed (FC):

-   bFC=total flights climbed over 1 year period/365 days-   FC will be organized in weekly manner-   Time to achieve bFC and beyond    -   Early Recovery (ER): those who achieved or exceeded pre-op bFC        within W12    -   Late Recovery (LR): those who achieved or exceeded pre-op bFC        from W13 to Y2    -   No Recovery (NR): those who never achieved or exceeded pre-op        bFC from WO to Y2    -   Deterioration (D): those who experience worsening in pre-op bFC        by Y2-   Grading the achievement from M6 to Y2    -   M6-Y2 FC will be defined by mean SM from M6 to Y2/540 days        -   Severe Worsening (SW): those who are 0% to 49% of bFC        -   Moderate Worsening (MoW): those who are 50% to 75% of bFC        -   Mild Worsening (MW): those who are 76% to 99% of bFC        -   Mild Recovery (MR): those who are 100% to 125% of bFC        -   Moderate Recovery (MoR): those who are 126% to 150% of bFC        -   Significant Recovery (SR): those who are 151% to 200% of bFC

TABLE 1 Example Grading Scheme Time to achieve Grading or exceedAchievements Composite baseline (0 to 2) (−3 to 3) Score SPD DPD ACB SMFC Total Score

-   Multivariate analysis and identify factors which contribute to (Odds    Ratio)    -   Surgical factors:        -   Cervical surgery        -   Lumbar surgery        -   Fusion vs. non-fusion        -   Number of levels    -   Demographics:        -   BMI        -   Age        -   Sex        -   Average preoperative activity level    -   Oswestry Disability Index for Lumbar Spine Surgery    -   Neck Disability Index for Cervical Spine Surgery

These outcomes will be compared to baseline and Y2 NDI for cervical andY2 ODI for lumbar surgeries:

-   NDI    -   Good outcome will be 0-28    -   Bad outcome will be 15-50-   ODI    -   Good outcome 0-20    -   Bad outcome 21-100

Pearson correlation coefficients were calculated between NDI/ODI andORBIT to check divergence.

Example of Patient Experience

An example patient experience is described below. Health metrics (stepstaken, distance travelled, flights climbed, standing minutes and energyexpenditure, etc.), patient traits (age, sex, ethnicity, co-morbidities,etc.), and surgery details (type of surgery, levels of surgery, locationof surgery, identity of surgeon/hospitals) are collected from 1000s ofpatients via the app.

-   a. Individual patients download the mobile app onto their    smartphones-   b. Mobile app determines pre-op and post-op health metrics based on    the date of surgery (e.g., by extracting existing health data stored    on the patient's smartphone)—the mobile app continues to collect    post-op health metrics-   c. Mobile app sends all data to the server

The system 106 analyzes the data received from 1000s of patients andgenerates a model.

Ms. Jones comes in for a checkup and consents to download the mobile appand share her activity data with the treating surgeon. Once the patientopens the app and consents to share the data, the app starts to uploadactivity data onto the HIPAA-compliant and encrypted cloud (e.g., system106 or data sources 160).

She downloads the mobile app:

-   d. Mobile app determines her pre-op health metrics-   e. Mobile app determines her patient traits-   f. Mobile app sends off the data to the server-   g. Server performs analysis using the model, generates projections,    sends to mobile app-   h. Mobile app processes the data downloaded from the server,    generates user interface into a dashboard displaying her activity    metrics and also into graphs

For patients who already underwent surgery, their pre-operative andpost-operative activity level is organized and displayed into adashboard. For those who has not undergone surgery yet, they can choosethe type of surgery they are expected to undergo on a future date. Themachine learning algorithm is then able to generate expected physicalactivity levels taking into consideration of the patient's baselinecharacteristics and baseline activity levels.

Type of surgery (e.g., minimally invasive or open, cervical or lumbar, 1or 2 levels of surgery) can be entered into the database. Mobile app isalso able to generate future expected activity level using machinelearning algorithm if the patient has not yet undergone surgery.

Surgery is performed:

-   i. Mobile app collects surgery detail from the treating surgeon and    the patient-   j. Mobile app begins collecting post-op health data-   k. Mobile app compares post-op data to previously generated    projection and to baseline and updated on weekly basis    -   i. Actual physical activity data can be compared to computer        generated data and any discrepancy can be calculated and        displayed in a graph and dashboard format    -   ii. Any discrepancy will be continuously fed back into the        machine learning algorithm to improve its accuracy and its        ability to predict-   l. Trigger feedback/suggestions to the patients and to the surgeons    -   i. If the patient is not meeting the expected milestones (e.g.        by 6 weeks post-op, if the patient is expected to be taking 5000        steps per day, but the patient is at 4000 steps per day), the        patient will receive an encourage message and a reminder to        their smartphone that they are reaching their expected activity        level. Not only the app will provide the feedback, it will        display the patient's physical activity data in a dashboard        fashion, so that the patient will be able to see their data        visualized in a succinct and organized fashion. In addition, the        patients will be able to see their ORBIT metric, which is a        composite objective activity measure that takes account of        multiple dimensions of physical activities, and also correlated        with established patient reported outcome measures (PROM)s.    -   ii. At the same time, the surgeon will have an option to be        notified and alerted if the patient has a sharp decline in their        activity level post-operatively, which may trigger a visit to        the emergency room or a follow-up in clinic.

Aggregated data from thousands of patients will be fed into machinelearning algorithm, which will continuously learn and improve over time.This algorithm will then be utilized to predict outcomes of othermedical or surgical interventions (e.g. a new anti-depressant medicationor orthopedic hip joint replacement).

Example Routine for Performing a Post-Operative Analysis of Patient Data

FIG. 3 depicts an illustrative routine 300 for performing apost-operative analysis of patient data in accordance with aspects ofthe present disclosure. The routine 300 may be carried out, for example,by the data analysis service 130 and/or the report generation service150 or one or more other components of the medical interventionanalytics system 106 described herein. For convenience, some or all ofthe steps of the routine 300 are described as being performed by thesystem 106. For example, the system 106 may include one or more hardwarecomputing devices and non-transitory physical computer storage storinginstructions that, when executed by the one or more hardware computingdevices, cause the one or more hardware computing devices to perform thesteps of the routine 300.

The routine 300 begins at block 302, at which the system 106 receives arequest to analyze a plurality of patients.

At block 304, the system 106 analyzes the activity data of one of theplurality of patients.

At block 306, the system 106 identifies one or more pre-op temporalwindows and one or more post-op temporal windows for the patient.

At block 308, the system 106 generates analytics data associated withthe patient.

At block 310, the system 106 determines whether there is any additionalpatient to be processed. If the system 106 determines that there existsan additional patient to be processed, the routine 300 returns to block304. Otherwise, the routine 300 proceeds to block 312.

At block 312, the system 106 stores the analytics data generated foreach patient in association with the biological traits data and thesurgery data associated with the corresponding one of the plurality ofpatients.

At block 314, the system 106 outputs a report based on the generatedanalytics data. The routine 300 may then end.

The routine 300 can include fewer, more, or different blocks than thoseillustrated in FIG. 3 and/or one or more blocks illustrated in FIG. 3may be modified, omitted, or switched without departing from the scopeof the description. Moreover, it will be appreciated by those skilled inthe art and others that some or all of the functions described in thisdisclosure may be embodied in software executed by one or moreprocessors of the medical intervention analytics system 106 and/or theuser computing device 102 disclosed herein.

Illustrative Graphs and User Interface Elements

FIG. 4 depicts graphs illustrating the activity data, in accordance withaspects of the present disclosure. Each graph shown in FIG. 4 shows thedaily activity data (solid line) with a user-adjustable moving average(dashed line, 25 days in FIG. 4). The vertical line represents the dateof surgery (all data to the left is pre-operative and to the right ispost-operative).

FIG. 5 depicts graphs illustrating the distribution of activity data, inaccordance with aspects of the present disclosure. The histograms shownin FIG. 5 demonstrate the distribution of activity both pre- andpost-operatively to allow for visual comparison of the activitydistributions before and after surgery.

FIG. 6 depicts graphs illustrating the mean activity levels with errorbars, in accordance with aspects of the present disclosure. Thebar-graphs shown in FIG. 6 demonstrate mean pre- and post-operativeactivity levels with error bars demonstrating the 95% confidenceinterval around the estimated mean. A unpaired two-tailed t-test is usedto determine the probability (p-value) that two independent samples fromthe pre-operative and post-operative distributions come from normaldistributions with equal means. This p-value is reported above the bargraph.

FIG. 7 depicts a graph illustrating the times of increased and decreasedactivity levels, in accordance with aspects of the present disclosure.In the graph shown in FIG. 7, the baseline activity is filtered with amoving-average (number of days is user selectable). High or low activityperiods are identified as those that vary from the mean by >than 1standard deviation (this could be made a user-selected variable). Theheight of the bars represents the average increase or decrease inactivity relative to the mean activity baseline. The width of the barrepresents the duration of the activity increase or decrease.

FIG. 8 depicts heat maps illustrating the levels of activity withoverlaid arrows, in accordance with aspects of the present disclosure.In the heat maps of FIG. 8, overlaid arrows indicate periods ofsignificant activity “ramp-up,” where the length and size (thickness ofline, size of arrowhead) correspond to the duration and slope ofactivity ramp-up. In FIG. 8, raw data was z-score normalized withrespect to the pre-operative period, and then smoothed using a 7-daysliding window. Periods of significant activity ramp-up were identifiedwith an optimization method with the following costs (e.g.,findchangepts.m in MATLAB): (1) the number of “change points” (linearpenalty weight for each number of change points); and (2) the sum ofsquared residuals of the linear fits of the data between the changepoints. It is noted that adding change points always decreases residualerror. For example, if each point in the time series is a change point,then the error sum of squares diminished to zero. Hence, the weights for(1) are important to avoid overfitting. The weights for (1) may bedetermined in an iterative, data-driven fashion such that the minimumnumber of days between change points was above a threshold value, e.g.,3 days (as ramp up of activity spanning only a day or two may not be asinteresting for this analysis).

FIG. 9 depicts graphs illustrating the levels of steps and step sizes,in accordance with aspects of the present disclosure. FIG. 10 depictsgraphs illustrating the levels of distances and flights, in accordancewith aspects of the present disclosure. In the graphs of FIGS. 9 and 10,raw data were z-score normalized with respect to the pre-operativedistribution, for each metric separately. X-axis indicates weeks fromsurgery. Values above 0 (y-axis) indicate daily level of activity at thepre-operative baseline. Within each sub-figure, data was plottedseparately for weekdays (dashed line), weekends (dotted line), and alltogether (solid line). Step size calculated as distance/steps. Data wasthen smoothed with a 7-day moving average. Days without data availablewere filled with NaN. In some embodiments, only the weekend activitydata may be used in performing the analyses described herein. In otherembodiments, only the weekday activity data may be used in performingthe analyses described herein. In yet other embodiments, both theweekday activity data and the weekend activity data may be used inperforming the analyses described herein.

FIG. 11 depicts graphs illustrating the pre-op and post-op levels ofsteps, distances, and flights for each day of the week, weekdays,weekend days, and all days, in accordance with aspects of the presentdisclosure. In FIG. 11, data is further stratified for pre-(shaded) andpost-operative (blank) period, and the error bars indicate the standarderror of the mean (SEM).

FIG. 12 depicts graphs illustrating the pre-op and post-op levels ofsteps in different types of scenarios including visual indications ofthe identified temporal windows (epochs), in accordance with aspects ofthe present disclosure. Based on the time series of daily level of stepsin the pre-operative period, the system 106 may automatically detectpre-defined “epochs”: 1) Epoch 1 is their pre-operative baseline state,where the patient was in their usual state of health (either healthy orchronically-debilitated); 2) Epoch 2 represents an acute decline (ifany) relative to their baseline, and represents the state the patientwould have been without intervention; 3) Epoch 3 is the post-surgicalrecovery period when the patients are recovering from acute surgicalpain, undergoing physical therapy/rehabilitation; 4) Epoch 4 representsa return to their new post-operative baseline level of activity, whichmay be on par with Epoch 1 or improved; 5) Epoch 5 was identified inpatient who had a secondary decline after a period of full recovery fromthe surgery. This may be due to re-aggravation of their injury, or adifferent disease state that may interfere with their mobility. Allsubjects have epochs 1 and 3, whereas epochs 2, 4, and 5 depend on theirspecific pre-operative pattern of activity. Epochs were identified afterz-score normalized raw data with respect to pre-operative distributionand smoothing with a 7-day sliding window. E2 was identified if therewas a period leading up to surgery (day=0) with mean steps <0 sustainedfor >10 days, with minimum steps <0.5. E4 was identified if there was aperiod in the post-operative period with mean steps >-0.25 sustainedfor >10 days. E5 was identified only if E4 was found, using the samecriteria as for E2. In other embodiments, any combination of mean steps,minimum steps, or sustained period may be used. In embodiments, E2 andE5 are configured to begin on a zero-crossing on a z-score normalizedgraph (e.g., where the graph crosses from a positive value to a negativevalue), and E4 is configured to begin on a zero-crossing on a z-scorenormalized graph (e.g., where the graph crosses from a negative value toa positive value). The techniques described with reference to FIG. 12may also be applied to FIGS. 19-21.

FIG. 13 depicts graphs illustrating comparisons of pre-op and post-opsteps, in accordance with aspects of the present disclosure, and FIG. 14depicts a graph illustrating a comparison of the skewness of pre-op andpost-op distribution of steps, in accordance with aspects of the presentdisclosure.

The graphs of FIG. 13 show a comparison of the mean daily steps betweenthe Epoch 2 vs. Epoch 4. If E2 is not available or identified, E1 may beused, and if E4 is not available or identified, E3 may be used. Theillustrated comparison measures the degree of improvement in daily stepsfollowing surgical intervention, comparing between the state the patientwould have been without surgery (E2 or E1) vs. after surgery (E4 or E3).Data points are plotted separately for patients with a full recovery (E4following E3 in post-operative period) and those without (only E3),using normalized data for visualization. Using raw steps instead mayalso provide qualitatively identical results.

The graph of FIG. 14 shows a comparison of the skewness of the pre- vspost-surgical distributions of daily steps. Analysis was conducted asfor mean daily steps, except without z-score normalization. Moreover,this comparison was conducted for data between El and E4. The underlyinghypothesis here was that the mobility data of a healthy person woulddemonstrate a positive skewness, as healthy people are able to ramp uptheir activities on certain days. Indeed, we found that a full recovery(as determined by time series analysis) was characterized by an increasein mean daily steps as well as skewness, or an increase in mean dailysteps without an increase in skewness. Although the relative importanceof mean vs. skewness remains to be determined with a larger data set,increases in mean (from pre- to post-op) is likely negatively correlatedwith increased in skewness.

Assisting Decision of whether to Undergo Surgery

FIG. 15 depicts an illustrative routine 1500 for assisting the decisionof whether to undergo a surgery or other medical intervention inaccordance with aspects of the present disclosure. As shown in FIG. 15,the routine 1500 may include (i) collecting input patient data (e.g.,sex, age, symptoms, activity data, details of the surgery that thepatient may undergo to improve her conditions, etc.), (ii) identifyingmachine learning algorithms to be used to determine predictedpost-operative activity data (e.g., step count, step size, traveldistance, flights of stairs climbed, calorie count, etc.), (iii)determining the predicted post-operative activity data, (iv) outputtinganalytics data to assist decision of whether a surgical intervention iswarranted, (v) identifying the optimal surgical intervention (e.g., bycomparing the predicted post-operative activity data for multiplesurgeries or types of surgeries), and (vi) tracking and providingsuggestions based on the patient's progress after the surgicalintervention.

Machine learning algorithm (MLA) is developed in parallel to predictindividual patient's outcome after a surgical intervention. Thealgorithm undergoes supervised learning by inputting known variables andthis will be used to predict the patient's activity levels aftersurgery. With this information, the physician and the patient can themake a decision to undergo surgery jointly based on predicted activitylevel as shown in FIG. 15. For instance, those patients who has not yetundergone surgery (e.g. one level lumbar discectomy) for radiculopathy,their activity levels and ORBIT metric post-operatively will bepredicted and this will be used to guide the surgery decision. UsingMLA, the patient's post-operative physical levels will be accuratelypredicted. MLA will be trained using the input of baseline patientcharacteristics (age, sex, BMI, medical conditions, bone density, etc.)and the prior examples of pre-operative and post-operative physicalactivity data from the patients who have already undergone surgery.Using MLA, the surgeon will be able to reliably inform a 40 year-oldlady about their post-operative course, after undergoing one levellumbar discectomy, based on thousands of patients with similar baselinehealth history and baseline activity level. Surgical approach, whetherthe surgery is done through minimally invasive or through open approach,will also be factored into the formation of MLA, therefore, both thepatient and the doctor will be able to choose the optimal surgicalintervention.

Example Routine for Performing Pre-Operative Analysis of Patient Data

FIG. 16 depicts an illustrative routine 1600 for performingpre-operative analysis of patient data in accordance with aspects of thepresent disclosure. The routine 1600 may be carried out, for example, bythe data analysis service 130 and/or the report generation service 150or one or more other components of the medical intervention analyticssystem 106 described herein. For convenience, some or all of the stepsof the routine 1600 are described as being performed by the system 106.For example, the system 106 may include one or more hardware computingdevices and non-transitory physical computer storage storinginstructions that, when executed by the one or more hardware computingdevices, cause the one or more hardware computing devices to perform thesteps of the routine 1600.

The routine 1600 begins at block 1602, at which the system 106 receivesa request to analyze a first patient.

At block 1604, the system 106 retrieves analytics data of previouslyanalyzed patients (e.g., as illustrated in FIG. 3) based on thebiological traits data associated with the first patient and a firstsurgery type (e.g., a type of surgery that is being considered for thefirst patient).

At block 1606, the system 106 determines a predicted efficacy score of afirst surgery of the first surgery type.

At block 1608, the system 106 determines a predicted pattern ofpost-operative recovery.

At block 1610, the system 106 outputs a report based on the predictedefficacy and predicted pattern of post-operative recovery. For example,the report may be presented to the user computing device 102 via amobile application or a browser application in the form of a userinterface that includes a user interface element indicative of thepredicted efficacy and another user interface element indicative of thepredicted pattern of post-operative recovery. The routine 1600 may thenend.

The routine 1600 can include fewer, more, or different blocks than thoseillustrated in FIG. 16 and/or one or more blocks illustrated in FIG. 16may be modified, omitted, or switched without departing from the scopeof the description. Moreover, it will be appreciated by those skilled inthe art and others that some or all of the functions described in thisdisclosure may be embodied in software executed by one or moreprocessors of the medical intervention analytics system 106 and/or theuser computing device 102 disclosed herein.

Example Routine for Outputting Visually Distinguished Temporal Windows

FIG. 17 depicts an illustrative routine 1700 for outputting visuallydistinguished temporal windows in accordance with aspects of the presentdisclosure. The routine 1700 may be carried out, for example, by thedata analysis service 130 and/or the report generation service 150 orone or more other components of the medical intervention analyticssystem 106 described herein. For convenience, some or all of the stepsof the routine 1700 are described as being performed by the system 106.For example, the system 106 may include one or more hardware computingdevices and non-transitory physical computer storage storinginstructions that, when executed by the one or more hardware computingdevices, cause the one or more hardware computing devices to perform thesteps of the routine 1700.

The routine 1700 begins at block 1702, at which the system 106 receivesa request to analyze a first patient.

At block 1704, the system 106 retrieves activity data associated withthe first patient.

At block 1706, the system 106 retrieves the date of surgery associatedwith the first patient.

At block 1708, the system 106 graphs the activity data associated withthe first patient relative to the date of surgery. For example, aportion of the activity data that precedes the surgery date may beplotted on the left side of the graph (e.g., to the left of the positionindicative of the surgery date), and the remaining portion of theactivity data that follows the surgery date may be plotted on the rightside of the graph (e.g., to the right of the position indicative of thesurgery date).

At block 1710, the system 106 identifies one or more pre-operativetemporal windows and one or more post-operative temporal windows for thefirst patient based on the activity data. The techniques for identifyingthe temporal windows are described in greater detail below withreference to FIG. 18.

At block 1712, the system 106 outputs graphical indicators that visuallydistinguish the activity in different temporal windows. For example,each section of the graph (or the plotted data point(s)) correspondingto a different temporal window may be in a different color (or differentshading, boldness, solid/dashed lines, etc.). The routine 1700 may thenend.

The routine 1700 can include fewer, more, or different blocks than thoseillustrated in FIG. 17 and/or one or more blocks illustrated in FIG. 17may be modified, omitted, or switched without departing from the scopeof the description. Moreover, it will be appreciated by those skilled inthe art and others that some or all of the functions described in thisdisclosure may be embodied in software executed by one or moreprocessors of the medical intervention analytics system 106 and/or theuser computing device 102 disclosed herein.

Example Routine for Identifying Temporal Windows Based on Sensor Data

FIG. 18 depicts an illustrative routine 1800 for identifying temporalwindows based on sensor data received from one or more computing devicesor activity tracking devices associated with a user in accordance withaspects of the present disclosure. The routine 1800 may be carried out,for example, by the data analysis service 130 and/or the reportgeneration service 150 or one or more other components of the medicalintervention analytics system 106 described herein. For convenience,some or all of the steps of the routine 1800 are described as beingperformed by the system 106. For example, the system 106 may include oneor more hardware computing devices and non-transitory physical computerstorage storing instructions that, when executed by the one or morehardware computing devices, cause the one or more hardware computingdevices to perform the steps of the routine 1800.

The routine 1800 begins at block 1802, at which the system 106 receivesthe sensor data associated with a user and a reference point associatedwith the user. For example, the sensor data may include on raw datacaptured by the user's smartphone or another computing device (e.g.,accelerometer data, gyroscope data, magnetometer data, etc., or anycombination thereof) and/or processed data generated on the user'ssmartphone or another computing device (e.g., step count, step size,travel distance, flights of stairs climbed, calorie count, etc.), andthe reference point may be a pre-determined time or date that is to beused as a reference for analyzing the received sensor data. In otherembodiments, the reference point is automatically determined by thesystem 106 by analyzing the sensor data (e.g., by identifying a point intime at which the sensor data exceeds a threshold level, drops below athreshold level, increases by a threshold amount, drops by a thresholdamount, increases at or above a threshold rate, drops at or above athreshold rate, etc.) over one or more threshold time windows.

At block 1804, the system 106 determines whether an acute change (e.g.,decline, or incline) is detected in the pre-reference portion of thesensor data (e.g., raw data, processed data, and/or activity data). Forexample, an acute change may be detected by determining whether theactivity (e.g., step count, or another value described herein) remainsbelow a threshold average level (e.g., zero in z-score normalized steps)for a threshold period of time (e.g., 10 days) while reaching at least athreshold minimum level (e.g., −0.5 in z-score normalized steps). Inanother example, any combination of these criteria (threshold averagelevel, threshold period of time, and/or threshold minimum level) may beused to detect an acute decline.

If the system 106 determines that an acute decline is not detected, theroutine 1800 proceeds to block 1806, where the system 106 identifies asingle temporal window (“pre-reference baseline” period) for all of thepre-reference portion of the sensor data. Otherwise, the routine 1800proceeds to block 1808.

At block 1808, the system 106 identifies one pre-reference temporalwindow (“pre-reference baseline” period) including all pre-referencesensor data prior to the acute decline, and another pre-referencetemporal window (“acute decline” period) including all pre-referencesensor data between the identified pre-reference temporal window and thereference point (e.g., surgery date or some other point in time).

At block 1810, the system 106 determines whether a recovery is detectedin the post-reference portion of the sensor data. For example, arecovery may be detected by determining whether the sensor data (e.g.,step count, or another value described herein) above a threshold averagelevel (e.g., −0.25 in z-score normalized steps) for a threshold periodof time (e.g., 10 days) while reaching at least a threshold maximumlevel (e.g., 0.25 in z-score normalized steps). In another example, anycombination of these criteria (threshold average level, threshold periodof time, and/or threshold maximum level) may be used to detect arecovery.

If the system 106 determines that a recovery is not detected, theroutine 1800 proceeds to block 1812, where the system 106 identifies asingle temporal window (“post-reference recovery” period) for all of thepost-reference portion of the sensor data. Otherwise, the routine 1800proceeds to block 1814.

At block 1814, the system 106 identifies one post-reference temporalwindow (“post-reference recovery” period) including all post-referencesensor data between the surgery date and the detected recovery, andanother pre-reference temporal window (“recovered” period) including allpost-reference sensor data after the identified post-reference temporalwindow.

At block 1816, the system 106 outputs a surgical efficacy score based onthe identified temporal windows. For example, the surgical efficacyscore may be calculated by dividing the average step count in the“recovered” period by the average step count in the “acute decline”period. As another example, the surgical efficacy score may becalculated by dividing the average step count in the “post-referencerecovery” period (e.g., if the “recovered” period is not identified) bythe average step count in the “pre-reference baseline” period (e.g., ifthe “acute decline” period is not identified). The routine 1800 may thenend.

The routine 1800 can include fewer, more, or different blocks than thoseillustrated in FIG. 18 and/or one or more blocks illustrated in FIG. 18may be modified, omitted, or switched without departing from the scopeof the description. For example, although not shown in FIG. 18, thesystem 106 may identify another temporal window subsequent to the“recovered” period, in response to detecting another acute decline(e.g., using the techniques described above) subsequent to the detectedrecovery. The identified temporal window may include the detectedpost-reference acute decline and the sensor data subsequent to thepost-reference acute decline. Moreover, it will be appreciated by thoseskilled in the art and others that some or all of the functionsdescribed in this disclosure may be embodied in software executed by oneor more processors of the medical intervention analytics system 106and/or the user computing device 102 disclosed herein.

Comparison of Temporal Windows

The system 106 may compare the lengths of E3 for different surgeries (orany other parameters associated with the surgeries, such as surgeon,medical device, device manufacturer, surgery length, type of druginfused or administered, amount of drug infused or administered, time ofday, pre-existing conditions, patient biological trait, etc.) todetermine which surgery or medical device shortens E3. Suchdetermination may be included in a report.

The system 106 may compare the amplitudes of E4 for different surgeries(or any other parameters associated with the surgeries, such as surgeon,medical device, device manufacturer, surgery length, type of druginfused or administered, amount of drug infused or administered, time ofday, pre-existing conditions, patient biological trait, etc.) todetermine which surgery or medical device results in higher E4. Suchdetermination may be included in a report.

The system 106 may compare the efficacy (e.g., E4 or E3 divided by E2 orE1) for different surgeries (or any other parameters associated with thesurgeries, such as surgeon, medical device, device manufacturer, surgerylength, type of drug infused or administered, amount of drug infused oradministered, time of day, pre-existing conditions, patient biologicaltrait, etc.) to determine which surgery or medical device results ingreater efficacy. Such determination may be included in a report.

Example Architecture of Computing System

FIG. 22 depicts an example architecture of a computing system 2200 thatcan be used to perform one or more of the techniques described herein orillustrated in FIGS. 1-18. The general architecture of the computingsystem 2200 depicted in FIG. 22 includes an arrangement of computerhardware and software modules that may be used to implement one or moreaspects of the present disclosure. The computing system 2200 may includemany more (or fewer) elements than those shown in FIG. 22. It is notnecessary, however, that all of these elements be shown in order toprovide an enabling disclosure. For example, the computing system 2200may be used to implement one or more of the elements described herein,including the data analysis service 130, the report generation service150, and/or the user computing devices 102.

As illustrated, the computing system 2200 includes a processor 190, anetwork interface 192, and a computer-readable medium 194, all of whichmay communicate with one another by way of a communication bus. Thenetwork interface 192 may provide connectivity to one or more networksor computing systems. The processor 190 may thus receive information andinstructions from other computing systems or services via the network104 illustrated in FIG. 1.

The processor 190 may also communicate with memory 180. The memory 180may contain computer program instructions (grouped as modules in someembodiments) that the processor 190 executes in order to implement oneor more aspects of the present disclosure. The memory 180 may includeRAM, ROM, and/or other persistent, auxiliary, or non-transitorycomputer-readable media. The memory 180 may store an operating system182 that provides computer program instructions for use by the processor190 in the general administration and operation of the computing system2200. The memory 180 may further include computer program instructionsand other information for implementing one or more aspects of thepresent disclosure. For example, in one embodiment, the memory 180includes a user interface module 184 that generates user interfaces(and/or instructions therefor) for display upon a user computing device(e.g., user computing device 102 of FIG. 1), e.g., via a navigationand/or browsing interface such as a browser or application installed onthe user computing device. In addition, the memory 180 may include orcommunicate with one or more data stores.

In addition to and/or in combination with the user interface module 184,the memory 180 may include a data analysis module 186 and a reportgeneration module 188 that may be executed by the processor 190. In oneembodiment, the data analysis module 186 and the report generationmodule 188 collectively implement various aspects of the presentdisclosure, e.g., those illustrated in FIGS. 1-21 or described withreference to FIGS. 1-21.

Although a single processor, a single network interface, a singlecomputer-readable medium, and a single memory are illustrated in theexample of FIG. 22, in other implementations, the computing system 2200can have a multiple of one or more of these components (e.g., two ormore processors and/or two or more memories).

Surgeries and Other Types of Interventions

Although surgery is used as an example in some embodiments describedherein, the techniques described in the present disclosure are notlimited to surgeries and can be applied, in other embodiments, to anyother types of treatments, procedures, or interventions.

Processed Activity Data

Although processed activity data (e.g., step count, step size, caloriecount, flights climbed, etc.) is described in some embodiments as beinggenerated by the patients' smartphones (e.g., by a mobile applicationinstalled on the smartphones) and provided to the system 106, in otherembodiments, such processed activity data may be generated by the system106 or another server based on raw data captured by the patients'smartphones (e.g., accelerometer data, gyroscope data, magnetometerdata, etc., or any combination thereof).

Retrieving and Visualizing Analytics Data in Patient-Trait-Specific andIntervention-Specific Manner

Based on the information associated with a given patient, the system 106may filter the previously generated analytics data, and generate anotherset of analytics data for presentation to the patient. For example, thesystem 106 may determine that the patient is female, belongs to a 50-60age group, and is considering a spine surgery. In response, the system106 may filter the analytics data for female, 50-60 age group, and spinesurgery, where the filtered analytics data indicate how other femalepatients in the age group who underwent a spine surgery performed beforeand after the surgery. Using this filtered data, the system 106 maynewly generate analytics data for the patient. This newly generatedanalytics data may include a efficacy score associated with one or moretypes of spine surgery (e.g., by averaging the efficacy scores of theother female patients in the age group), and a respective predictedpattern of recovery (e.g., mobility levels) for each medicalintervention. Based on the newly generated analytics data, a visualreport may be generated for presentation to the patient and/or anotheruser evaluating the medical intervention options on behalf of the user.Although this example only used gender and age group, any number ofpatient traits can be used in filtering the previously generatedanalytics data and/or generating the new analytics data for the patient.Also, although this example is used for providing analytics data for anew patient, in other embodiments, similar techniques may be used tocompare the efficacy scores of various other criteria that may affectthe outcome (e.g., medical practitioner, medical intervention date,medical device used, medical device manufacturer, medical interventionduration, type of drug infused or administered, amount of drug infusedor administered, level of invasiveness, medical intervention time ofday, etc.) and/or any other combination of patient traits using existingpatients' data. For example, a report comparing multiple medicalpractitioners, multiple medical devices, multiple medical devicemanufacturers, multiple medical intervention durations, multiple typesof drugs infused or administered, different amounts of drug infused oradministered, multiple levels of invasiveness, and/or multiple medicalintervention times of day can be generated and presented to the user. Insome embodiments, predicted pattern of post-operative recovery can begenerated for an existing patient who has already undergone a medicalintervention.

In some embodiments, intervention-specific modifiers or weights may bestored and retrieved for weighing the sensor data differently dependingon the intervention. For example, gait size may be weighted more heavilythan step count or stairs climbed for one intervention or type ofintervention, and in such a case, gait size may have a greater impact onthe activity level (or level of sensor data or mobility level) used inthe figures and/or graphs shown herein. In some embodiments, activityintensity/level shown in the figures and/or graphs shown herein areaggregate values collected from multiple users across multipleindicators (e.g., gait size, step count, stairs climbed, etc.). In otherembodiments, activity intensity/level shown in the figures and/or graphsshown herein are aggregate values collected from multiple patients/usersfor a single indicator (e.g., gait size, step count, stairs climbed,etc.). In other embodiments, activity intensity/level shown in thefigures and/or graphs shown herein are aggregate values collected for asingle patient/user for a single indicator (e.g., gait size, step count,stairs climbed, etc.).

Example Implementations (EIs)

Some enumerated example implementations (EIs) are provided in thissection, without limitation.

EI 1: A system for providing analytics relating to patients andsurgeries, the system comprising: a data repository storing analyticsdata associated with one or more patients; and a data analysis servicecomprising computer hardware, wherein the data analysis service isconfigured to at least: receive a first request to analyze a pluralityof patients, wherein the first request includes (i) biological traitsdata associated with the plurality of patients, (i) step count datagenerated by a plurality of respective user computing devices associatedwith the plurality of patients, and (iii) surgery data associated withthe plurality of patients; and for each respective patient of theplurality of patients: identify a set of temporal windows based at leastin part on the step count data associated with the respective patient;select, from the set of temporal windows, a first temporal window priorto a surgery date associated with the respective patient and a secondtemporal window subsequent to the surgery date; generate a surgicalefficacy score based at least in part on a comparison of first stepcount data associated with the first temporal window and second stepcount data associated with the second temporal window; and store thesurgical efficacy score in association with (a) at least a portion ofthe biological traits data associated with the respective patient and(b) at least a portion of the surgery data associated with therespective patient, such that the surgical efficacy score associatedwith the respective patient is retrievable in abiological-trait-specific and surgery-specific manner, wherein the dataanalysis service is further configured to: receive a second request toanalyze a first patient not included in the plurality of patients,wherein the second request includes (i) first biological traits dataassociated with the first patient, (ii) first step count data associatedwith the first patient, and (iii) a first surgery type; retrieve, fromthe data repository, first analytics data based at least in part on thefirst biological traits data and the first surgery type, wherein thefirst analytics data is a subset of the analytics data stored in thedata repository that corresponds to at least a portion of the firstbiological traits data and the first surgery type; determine, based atleast in part on the first analytics data and the first step count dataassociated with the first patient, (a) a predicted surgical efficacyscore associated with performing a first surgery of the first surgerytype on the first patient and (b) a predicted pattern of post-surgeryrecovery associated with performing the first surgery on the firstpatient; and output a report associated with the first patient, whereinthe report indicates at least the predicted surgical efficacy score andthe predicted pattern of recovery.

EI 2: The system of EI 1, wherein the surgical efficacy score iscalculated by dividing a first average value of the second step countdata over the second temporal window by a second average value of thefirst step count data over the first temporal window.

EI 3: The system of EI 1, wherein the predicted pattern of post-surgeryrecovery is determined by aggregating a post-operative portion of thestep count data of a subset of the plurality of patients that share aset of the same biological traits of the first patient.

EI 4: The system of EI 1, wherein the data analysis service is furtherconfigured to: determine the predicted surgical efficacy score for eachof a plurality of surgeries including the first surgery; and output arecommendation for the first surgery based at least in part on (i) thepredicted surgical efficacy score associated with the first surgerybeing the highest out of the plurality of surgeries, and (ii) thepredicted surgical efficacy score associated with the first surgeryindicating that the first surgery is predicted to result in at least athreshold level of mobility improvement for the first patient.

EI 5: The system of EI 1, wherein the step count data comprises, for agiven patient of the plurality of patients, a number of steps estimatedto be taken by the given patient based on sensor data captured by one ormore sensors of a smartphone associated with the given patient, whereinthe one or more sensors include one or more of an accelerometer, agyroscope, a global positioning system (GPS) sensor, a compass, amagnetometer, or a barometer.

EI 6: The system of EI 1, wherein the step count data is collected by amobile application installed on each of the plurality of respective usercomputing devices associated with the plurality of patients andtransmitted to a data repository accessible by the data analysisservice.

EI 7: The system of EI 1, wherein the data analysis service is furtherconfigured to: identify a first subset of the analytics datacorresponding to a first subset of patients of the plurality of patientswho have undergone the first surgery and are associated with a first setof biological traits; identify a second subset of the analytics datacorresponding to a second subset of patients of the plurality ofpatients who have undergone the first surgery and are associated with asecond set of biological traits different from the first set ofbiological traits; and output an aggregate report including (i) a firstsurgical efficacy score associated with the first surgery for the firstsubset of patients associated with the first set of biological traits,and (ii) a second surgical efficacy score associated with the firstsurgery for the second subset of patients associated with the second setof biological traits.

EI 8: The system of EI 1, wherein the data analysis service is furtherconfigured to: identify a first subset of the analytics datacorresponding to a first subset of patients of the plurality of patientswho have undergone the first surgery and are associated with a first setof biological traits; identify a second subset of the analytics datacorresponding to a second subset of patients of the plurality ofpatients who have undergone a second surgery different from the firstsurgery and are associated with the first set of biological traits; andoutput an aggregate report including (i) a first surgical efficacy scoreassociated with the first surgery for the first subset of patientsassociated with the first set of biological traits, and (ii) a secondsurgical efficacy score associated with the second surgery for the firstsubset of patients associated with the first set of biological traits.

EI 9: A computer-implemented method for providing analytics relating topatients and medical interventions, the method comprising: receiving afirst request to analyze a plurality of patients, wherein the firstrequest includes (i) biological traits data associated with theplurality of patients, (i) activity data associated with the pluralityof patients, and (iii) medical intervention data associated with theplurality of patients; for each respective patient of the plurality ofpatients: identifying a set of temporal windows based at least in parton the activity data associated with the respective patient, wherein theset of temporal windows includes at least (i) a first temporal windowprior to a medical intervention date associated with the respectivepatient, and (ii) a second temporal window subsequent to the medicalintervention date; generating analytics data including a medicalintervention efficacy score based at least in part on a comparison offirst activity data associated with the first temporal window and secondactivity data associated with the second temporal window; and storingthe analytics data in association with (a) at least a portion of thebiological traits data associated with the respective patient and (b) atleast a portion of the medical intervention data associated with therespective patient, receiving a second request to analyze a firstpatient, wherein the second request includes (i) first biological traitsdata associated with the first patient, (ii) first activity dataassociated with the first patient, and (iii) first medical interventiondata; retrieving first analytics data based at least in part on thefirst biological traits data and the first medical intervention data,wherein the first analytics data is a subset of the analytics datagenerated based on the activity data associated with the plurality ofpatients that corresponds to at least a portion of the first biologicaltraits data and the first medical intervention data; determining, basedat least in part on the first analytics data and the first activity dataassociated with the first patient, (a) a predicted medical interventionefficacy score associated with performing a first medical interventionassociated with the first medical intervention data on the first patientand (b) a predicted pattern of post-intervention recovery associatedwith performing the first medical intervention on the first patient; andoutputting a report associated with the first patient, wherein thereport indicates at least the predicted medical intervention efficacyscore and the predicted pattern of recovery.

EI 10: The computer-implemented method of EI 9, wherein the activitydata includes one or more of step count, step size, distance traveled,or flights of stairs climbed.

EI 11: The computer-implemented method of EI 9, wherein the medicalintervention data includes one or more of a medical practitioner, amedical intervention date, a medical device used, a medical devicemanufacturer, a medical intervention duration, or a medical interventiontime of day.

EI 12: The computer-implemented method of EI 9, wherein the medicalintervention efficacy score is calculated by dividing a first averagevalue of the second activity data over the second temporal window by asecond average value of the first activity data over the first temporalwindow.

EI 13: The computer-implemented method of EI 9, wherein the predictedpattern of post-intervention recovery is determined by aggregating apost-operative portion of the activity data of a subset of the pluralityof patients that share a set of the same biological traits of the firstpatient.

EI 14: The computer-implemented method of EI 9, further comprising:determining the predicted medical intervention efficacy score for eachof a plurality of medical interventions associated with the firstmedical intervention data, wherein the plurality of medicalinterventions includes the first medical intervention; and outputting arecommendation for the first medical intervention based at least in parton (i) the predicted medical intervention efficacy score associated withthe first medical intervention being the highest out of the plurality ofmedical interventions, and (ii) the predicted medical interventionefficacy score associated with the first medical intervention indicatingthat the first medical intervention is predicted to result in at least athreshold level of mobility improvement for the first patient.

EI 15: The computer-implemented method of EI 9, further comprising:identifying a first subset of the analytics data corresponding to afirst subset of patients of the plurality of patients who have undergonethe first medical intervention and are associated with a first set ofbiological traits; identifying a second subset of the analytics datacorresponding to a second subset of patients of the plurality ofpatients who have undergone a second medical intervention different fromthe first medical intervention and are associated with the first set ofbiological traits; and outputting an aggregate report including (i) afirst medical intervention efficacy score associated with the firstmedical intervention for the first subset of patients associated withthe first set of biological traits, and (ii) a second medicalintervention efficacy score associated with the second medicalintervention for the first subset of patients associated with the firstset of biological traits.

EI 16: A non-transitory computer readable medium storing instructionsthat, when executed by a computing system, cause the computing system toperform operations comprising: receiving a first request to analyze aplurality of patients, wherein the first request includes (i) biologicaltraits data associated with the plurality of patients, (i) activity dataassociated with the plurality of patients, and (iii) medicalintervention data associated with the plurality of patients; for eachrespective patient of the plurality of patients: identifying a set oftemporal windows based at least in part on the activity data associatedwith the respective patient, wherein the set of temporal windowsincludes at least (i) a first temporal window prior to a medicalintervention date associated with the respective patient, and (ii) asecond temporal window subsequent to the medical intervention date;generating analytics data including a medical intervention efficacyscore based at least in part on a comparison of first activity dataassociated with the first temporal window and second activity dataassociated with the second temporal window; and storing the analyticsdata in association with (a) at least a portion of the biological traitsdata associated with the respective patient and (b) at least a portionof the medical intervention data associated with the respective patient,receiving a second request to analyze a first patient, wherein thesecond request includes (i) first biological traits data associated withthe first patient, (ii) first activity data associated with the firstpatient, and (iii) first medical intervention data; retrieving firstanalytics data based at least in part on the first biological traitsdata and the first medical intervention data, wherein the firstanalytics data is a subset of the analytics data generated based on theactivity data associated with the plurality of patients that correspondsto at least a portion of the first biological traits data and the firstmedical intervention data; determining, based at least in part on thefirst analytics data and the first activity data associated with thefirst patient, (a) a predicted medical intervention efficacy scoreassociated with performing a first medical intervention associated withthe first medical intervention data on the first patient and (b) apredicted pattern of post-intervention recovery associated withperforming the first medical intervention on the first patient; andoutputting a report associated with the first patient, wherein thereport indicates at least the predicted medical intervention efficacyscore and the predicted pattern of recovery.

EI 17: The non-transitory computer readable medium of EI 16, wherein themedical intervention efficacy score is calculated by dividing a firstaverage value of the second activity data over the second temporalwindow by a second average value of the first activity data over thefirst temporal window.

EI 18: The non-transitory computer readable medium of EI 16, wherein thepredicted pattern of post-intervention recovery is determined byaggregating a post-operative portion of the activity data of a subset ofthe plurality of patients that share a set of the same biological traitsof the first patient.

EI 19: The non-transitory computer readable medium of EI 16, storingfurther instructions that, when executed by the computing system, causethe computing system to perform operations comprising: determining thepredicted medical intervention efficacy score for each of a plurality ofmedical interventions associated with the first medical interventiondata, wherein the plurality of medical interventions includes the firstmedical intervention; and outputting a recommendation for the firstmedical intervention based at least in part on (i) the predicted medicalintervention efficacy score associated with the first medicalintervention being the highest out of the plurality of medicalinterventions, and (ii) the predicted medical intervention efficacyscore associated with the first medical intervention indicating that thefirst medical intervention is predicted to result in at least athreshold level of mobility improvement for the first patient.

EI 20: The non-transitory computer readable medium of EI 16, storingfurther instructions that, when executed by the computing system, causethe computing system to perform operations comprising: identifying afirst subset of the analytics data corresponding to a first subset ofpatients of the plurality of patients who have undergone the firstmedical intervention and are associated with a first set of biologicaltraits; identifying a second subset of the analytics data correspondingto a second subset of patients of the plurality of patients who haveundergone a second medical intervention different from the first medicalintervention and are associated with the first set of biological traits;and outputting an aggregate report including (i) a first medicalintervention efficacy score associated with the first medicalintervention for the first subset of patients associated with the firstset of biological traits, and (ii) a second medical interventionefficacy score associated with the second medical intervention for thefirst subset of patients associated with the first set of biologicaltraits.

EI 21: A novel system and method to capture and transfer data fromsmartphones to a secure, encrypted, HIPAA-compliant network, comprising:automated de-identification of the personal health information (PHI) andassignment of unique identifier to each patient. This will ensure datasecurity so that PHI is protected and even if breached, a hacker willnot be able to match the medical history data back to individual patientin our database; and continuous data collection and processing allow fororganized data visualization for numerous patients. The database will beconstantly updated as well as new patients will sign up and download themobile application.

EI 22: An ORBIT scoring system based on physical function of an user,wherein the scoring system ranges from −15 to 25, with higher scorerepresenting higher level of physical activity, wherein the ORBITscoring system is a weighted scoring system with two components:temporal and gradient. Temporal grade is based on time to exceedbaseline physical activity level from surgery, and gradient is gradedbased on the amount of increase or decrease in physical activity levelcompared to the baseline activity level, wherein ORBIT is a novel scorecalculated from the smartphone accelerometer data that is constantlybeing collected and stored using each device's algorithm (Apple iPhone),and wherein after physical activity data is imported from participant'scellular device, five parameters (SPD, DPD, ACB, SM, FC) are collectedand organized into daily, weekly and monthly averages. Based on thesedata, ORBIT score is calculated for each patient and compared againstconventional PROM (ODI, NDI, PROMIS) to determine either convergence ordivergence, wherein ORBIT represents temporally continuous variable asopposed to PROM which is calculated at a single time point when thepatient fills out a survey, thus allowing early detection of improvementor worsening during patient's recovery from surgery, which may alert thepatient or the treating physician and trigger a close monitoring orfollow-up, and wherein the present disclosure allows for real-time,continuously updated, objective, reliable, accurate and consistentassessment of patient's progress through surgical intervention such thatthis method for objective outcome measures may cause a fundamentalparadigm shift towards value-based reimbursement model forMedicare/Medicaid/private insurance companies and away from traditionalfee-for-service model.

EI 23: Supervised machine learning algorithm (MLA) that will be able topredict a user's future activity level based on historical activitydata, demographic and relevant medical history, wherein the MLA can betrained by inputting clinical variables and relevant medical history topredict future outcomes for those patients who has not undergone surgeryyet, wherein MLA will calculate future physical activity levels (SPD,DPD, ACB, SM, FC) of the patient based on pre-op baseline physicalactivity levels, baseline demographics such as age, sex, BMI, medicalhistory, type of surgery and invasiveness of surgery, wherein based onpredicted SPD, DPD, ACB, SM, FC, predicted ORBIT will be calculated foreach patient based on different types of surgery (e.g. microdiscectomy,fusion, open versus minimally invasive spine surgery), and wherein basedon these predictions, a clinician and a patient can decide which type ofsurgery is best suited for each patient.

Terminology

All of the methods and tasks described herein may be performed and fullyautomated by a computer system. The computer system may, in some cases,include multiple distinct computers or computing devices (e.g., physicalservers, workstations, storage arrays, cloud computing resources, etc.)that communicate and interoperate over a network to perform thedescribed functions. Each such computing device typically includes aprocessor (or multiple processors) that executes program instructions ormodules stored in a memory or other non-transitory computer-readablestorage medium or device (e.g., solid state storage devices, diskdrives, etc.). The various functions disclosed herein may be embodied insuch program instructions, or may be implemented in application-specificcircuitry (e.g., ASICs or FPGAs) of the computer system. Where thecomputer system includes multiple computing devices, these devices may,but need not, be co-located. The results of the disclosed methods andtasks may be persistently stored by transforming physical storagedevices, such as solid-state memory chips or magnetic disks, into adifferent state. In some embodiments, the computer system may be acloud-based computing system whose processing resources are shared bymultiple distinct business entities or other users.

The processes described herein or illustrated in the figures of thepresent disclosure may begin in response to an event, such as on apredetermined or dynamically determined schedule, on demand wheninitiated by a user or system administrator, or in response to someother event. When such processes are initiated, a set of executableprogram instructions stored on one or more non-transitorycomputer-readable media (e.g., hard drive, flash memory, removablemedia, etc.) may be loaded into memory (e.g., RAM) of a server or othercomputing device. The executable instructions may then be executed by ahardware-based computer processor of the computing device. In someembodiments, such processes or portions thereof may be implemented onmultiple computing devices and/or multiple processors, serially or inparallel.

Depending on the embodiment, certain acts, events, or functions of anyof the processes or algorithms described herein can be performed in adifferent sequence, can be added, merged, or left out altogether (e.g.,not all described operations or events are necessary for the practice ofthe algorithm). Moreover, in certain embodiments, operations or eventscan be performed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors or processor cores or onother parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules, routines, andalgorithm steps described in connection with the embodiments disclosedherein can be implemented as electronic hardware (e.g., ASICs or FPGAdevices), computer software that runs on computer hardware, orcombinations of both. Moreover, the various illustrative logical blocksand modules described in connection with the embodiments disclosedherein can be implemented or performed by a machine, such as a processordevice, a digital signal processor (“DSP”), an application specificintegrated circuit (“ASIC”), a field programmable gate array (“FPGA”) orother programmable logic device, discrete gate or transistor logic,discrete hardware components, or any combination thereof designed toperform the functions described herein. A processor device can be amicroprocessor, but in the alternative, the processor device can be acontroller, microcontroller, or state machine, combinations of the same,or the like. A processor device can include electrical circuitryconfigured to process computer-executable instructions. In anotherembodiment, a processor device includes an FPGA or other programmabledevice that performs logic operations without processingcomputer-executable instructions. A processor device can also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration. Although described herein primarily with respect todigital technology, a processor device may also include primarily analogcomponents. For example, some or all of the rendering techniquesdescribed herein may be implemented in analog circuitry or mixed analogand digital circuitry. A computing environment can include any type ofcomputer system, including, but not limited to, a computer system basedon a microprocessor, a mainframe computer, a digital signal processor, aportable computing device, a device controller, or a computationalengine within an appliance, to name a few.

The elements of a method, process, routine, or algorithm described inconnection with the embodiments disclosed herein can be embodieddirectly in hardware, in a software module executed by a processordevice, or in a combination of the two. A software module can reside inRAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory,registers, hard disk, a removable disk, a CD-ROM, or any other form of anon-transitory computer-readable storage medium. An exemplary storagemedium can be coupled to the processor device such that the processordevice can read information from, and write information to, the storagemedium. In the alternative, the storage medium can be integral to theprocessor device. The processor device and the storage medium can residein an ASIC. The ASIC can reside in a user terminal. In the alternative,the processor device and the storage medium can reside as discretecomponents in a user terminal.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements or steps.Thus, such conditional language is not generally intended to imply thatfeatures, elements or steps are in any way required for one or moreembodiments or that one or more embodiments necessarily include logicfor deciding, with or without other input or prompting, whether thesefeatures, elements or steps are included or are to be performed in anyparticular embodiment. The terms “comprising,” “including,” “having,”and the like are synonymous and are used inclusively, in an open-endedfashion, and do not exclude additional elements, features, acts,operations, and so forth. Also, the term “or” is used in its inclusivesense (and not in its exclusive sense) so that when used, for example,to connect a list of elements, the term “or” means one, some, or all ofthe elements in the list.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, or Z). Thus,such disjunctive language is not generally intended to, and should not,imply that certain embodiments require at least one of X, at least oneof Y, and at least one of Z to each be present.

Any process descriptions, elements or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or elements in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown, or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved as would be understood by those skilled in the art.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B, andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it can beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the scope of the disclosure. As can berecognized, certain embodiments described herein can be embodied withina form that does not provide all of the features and benefits set forthherein, as some features can be used or practiced separately fromothers. All changes which come within the meaning and range ofequivalency of the claims are to be embraced within their scope.

What is claimed is:
 1. A system for providing analytics relating toaccelerometer data generated on computing devices, the systemcomprising: a data repository comprising computer hardware and storinganalytics data associated with one or more computing devices; and a dataanalysis server comprising computer hardware, wherein the data analysisservice is configured to at least: receive a first request to analyzehistorical accelerometer data collected from a plurality of computingdevices, wherein the first request includes (i) first characteristicsdata associated with the plurality of computing devices, and (ii) secondcharacteristics data associated with a plurality of target actions,wherein at least a first subset of the historical accelerometer data isassociated with a first type of target actions and a second subset ofthe historical accelerometer data is associated with a second type oftarget actions different from the first type of target actions; andidentify a set of temporal windows based at least in part on thehistorical accelerometer data associated with a first computing deviceof the plurality of computing devices and a first target actionassociated with a reference point, wherein identifying the set oftemporal windows comprises one or both of (i) identifying two or morepre-reference temporal windows preceding the reference point based atleast in part on the historical accelerometer data collected prior tothe reference point exhibiting a first threshold level of change, or(ii) two or more post-reference temporal windows following the referencepoint based at least in part on the historical accelerometer datacollected subsequent to the reference point exhibiting a secondthreshold level of change different from the first threshold level ofchange; generate outcome data based at least in part on a comparison ofthe historical accelerometer data in two or more temporal windows of theset of temporal windows, wherein the outcome data indicates a level ofeffectiveness of the first target action for the historicalaccelerometer data collected from the first computing device; and store,in the data repository, the outcome data in association with (a) atleast a portion of the first characteristics data associated with thefirst computing device and (b) at least a portion of the secondcharacteristics data associated with the first target action, such thatthe outcome data is retrievable in a characteristics-specific manner,wherein the data analysis server is further configured to: receive, froma second computing device, a second request to analyze additionalaccelerometer data collected from a third computing device and notincluded in the historical accelerometer data, wherein the secondrequest includes third characteristics data associated with the thirdcomputing device not included in the plurality of computing devices;retrieve, from the data repository, first analytics data based at leastin part on the third characteristics data and a second target action ofthe plurality of target actions, wherein the first analytics data is asubset of the outcome data stored in the data repository thatcorresponds to at least a portion of the third characteristics data andthe second target action; determine, based at least in part on the firstanalytics data and the additional accelerometer data collected from thethird computing device, (a) a predicted effectiveness value associatedwith the second target action for the additional accelerometer data and(b) an indication of predicted accelerometer data values to be collectedfrom the third computing device subsequent to the second target action;retrieve, from the data repository, second analytics data based at leastin part on the third characteristics data and a third target action ofthe plurality of target actions different from the second target action,wherein the second analytics data is a subset of the outcome data storedin the data repository that corresponds to at least a portion of thethird characteristics data and the third target action; determine, basedat least in part on the second analytics data and the additionalaccelerometer data collected from the third computing device, (c) apredicted effectiveness value associated with the third target actionfor the additional accelerometer data and (d) an indication of predictedaccelerometer data values to be collected from the third computingdevice subsequent to the third target action; generate one or both of(i) a first comparison of (a) the predicted effectiveness valueassociated with the second target action for the additionalaccelerometer data and (c) the predicted effectiveness value associatedwith the third target action for the additional accelerometer data, or(ii) a second comparison of (b) the indication of predictedaccelerometer data values to be collected from the third computingdevice subsequent to the second target action and (d) the indication ofpredicted sensor data values to be collected from the third computingdevice subsequent to the third target action; and output, via a userinterface associated with the second computing device, a visualizationof one or both of the first comparison or the second comparison.
 2. Thesystem of claim 1, wherein the first target action is identical to thesecond target action.
 3. The system of claim 1, wherein the first targetaction is different from the second target action.
 4. The system ofclaim 1, wherein the plurality of target action includes one or more ofa surgical intervention, a therapy, a drug, or a method.
 5. The systemof claim 1, wherein the first target action is associated with one ormore of a medical practitioner, a medical intervention date, a medicaldevice used, a medical device manufacturer, a drug infused, an amount ofdrug infused, a medical intervention duration, or a medical interventiontime of day.
 6. A computer-implemented method for providing analyticsrelating to patients and medical interventions, the method comprising:receiving a first request to analyze historical sensor data collectedfrom a plurality of computing devices, wherein the first requestincludes (i) first characteristics data associated with the plurality ofcomputing devices, and (ii) second characteristics data associated witha plurality of target actions, wherein at least a first subset of thehistorical sensor data is associated with a first type of target actionsand a second subset of the historical sensor data is associated with asecond type of target actions different from the first type of targetactions; and identifying a set of temporal windows based at least inpart on the historical sensor data associated with a first computingdevice of the plurality of computing devices and a first target actionassociated with a reference point, wherein identifying the set oftemporal windows comprises one or both of (i) identifying two or morepre-reference temporal windows preceding the reference point based atleast in part on the historical sensor data collected prior to thereference point exhibiting a first threshold level of change, or (ii)two or more post-reference temporal windows following the referencepoint based at least in part on the historical sensor data collectedsubsequent to the reference point exhibiting a second threshold level ofchange different from the first threshold level of change; generatingoutcome data based at least in part on a comparison of the historicalsensor data in two or more temporal windows of the set of temporalwindows, wherein the outcome data indicates a level of effectiveness ofthe first target action for the historical sensor data collected fromthe first computing device; and storing, in a data repository, theoutcome data in association with (a) at least a portion of the firstcharacteristics data associated with the first computing device and (b)at least a portion of the second characteristics data associated withthe first target action, such that the outcome data is retrievable in acharacteristics-specific manner; receiving, from a second computingdevice, a second request to analyze additional sensor data collectedfrom a third computing device and not included in the historical sensordata, wherein the second request includes third characteristics dataassociated with the third computing device not included in the pluralityof computing devices; retrieving, from the data repository, firstanalytics data based at least in part on the third characteristics dataand a second target action of the plurality of target actions, whereinthe first analytics data is a subset of the outcome data stored in thedata repository that corresponds to at least a portion of the thirdcharacteristics data and the second target action; determining, based atleast in part on the first analytics data and the additional sensor datacollected from the third computing device, (a) a predicted effectivenessvalue associated with the second target action for the additional sensordata and (b) an indication of predicted sensor data values to becollected from the third computing device subsequent to the secondtarget action; retrieving, from the data repository, second analyticsdata based at least in part on the third characteristics data and athird target action of the plurality of target actions different fromthe second target action, wherein the second analytics data is a subsetof the outcome data stored in the data repository that corresponds to atleast a portion of the third characteristics data and the third targetaction; determining, based at least in part on the second analytics dataand the additional sensor data collected from the third computingdevice, (c) a predicted effectiveness value associated with the thirdtarget action for the additional sensor data and (d) an indication ofpredicted sensor data values to be collected from the third computingdevice subsequent to the third target action; generating one or both of(i) a first comparison of (a) the predicted effectiveness valueassociated with the second target action for the additional sensor dataand (c) the predicted effectiveness value associated with the thirdtarget action for the additional sensor data, or (ii) a secondcomparison of (b) the indication of predicted sensor data values to becollected from the third computing device subsequent to the secondtarget action and (d) the indication of predicted sensor data values tobe collected from the third computing device subsequent to the thirdtarget action; and outputting, via a user interface associated with thesecond computing device, a visualization of one or both of the firstcomparison or the second comparison.
 7. The computer-implemented methodof claim 6, wherein the first target action is identical to the secondtarget action.
 8. The computer-implemented method of claim 6, whereinthe first target action is different from the second target action. 9.The computer-implemented method of claim 6, wherein the sensor dataincludes one or more of step count, step size, distance traveled, orflights of stairs climbed.
 10. The computer-implemented method of claim6, wherein the sensor data includes one or more of accelerometer data,gyroscope data, magnetometer data, or calorimeter data.
 11. Thecomputer-implemented method of claim 6, wherein the plurality of targetaction includes one or more of a surgical intervention, a therapy, adrug, or a method.
 12. The computer-implemented method of claim 6,wherein the first target action is associated with one or more of amedical practitioner, a medical intervention date, a medical deviceused, a medical device manufacturer, a drug infused, an amount of druginfused, a medical intervention duration, or a medical intervention timeof day.
 13. A non-transitory computer-readable medium storinginstructions that, when executed by a computing system, cause thecomputing system to perform operations comprising: receiving a firstrequest to analyze historical sensor data collected from a plurality ofcomputing devices, wherein the first request includes (i) firstcharacteristics data associated with the plurality of computing devices,and (ii) second characteristics data associated with a plurality oftarget actions, wherein at least a first subset of the historical sensordata is associated with a first type of target actions and a secondsubset of the historical sensor data is associated with a second type oftarget actions different from the first type of target actions; andidentifying a set of temporal windows based at least in part on thehistorical sensor data associated with a first computing device of theplurality of computing devices and a first target action associated witha reference point, wherein identifying the set of temporal windowscomprises one or both of (i) identifying two or more pre-referencetemporal windows preceding the reference point based at least in part onthe historical sensor data collected prior to the reference pointexhibiting a first threshold level of change, or (ii) two or morepost-reference temporal windows following the reference point based atleast in part on the historical sensor data collected subsequent to thereference point exhibiting a second threshold level of change differentfrom the first threshold level of change; generating outcome data basedat least in part on a comparison of the historical sensor data in two ormore temporal windows of the set of temporal windows, wherein theoutcome data indicates a level of effectiveness of the first targetaction for the historical sensor data collected from the first computingdevice; and storing, in a data repository, the outcome data inassociation with (a) at least a portion of the first characteristicsdata associated with the first computing device and (b) at least aportion of the second characteristics data associated with the firsttarget action, such that the outcome data is retrievable in acharacteristics-specific manner; receiving, from a second computingdevice, a second request to analyze additional sensor data collectedfrom a third computing device and not included in the historical sensordata, wherein the second request includes third characteristics dataassociated with the third computing device not included in the pluralityof computing devices; retrieving, from the data repository, firstanalytics data based at least in part on the third characteristics dataand a second target action of the plurality of target actions, whereinthe first analytics data is a subset of the outcome data stored in thedata repository that corresponds to at least a portion of the thirdcharacteristics data and the second target action; determining, based atleast in part on the first analytics data and the additional sensor datacollected from the third computing device, (a) a predicted effectivenessvalue associated with the second target action for the additional sensordata and (b) an indication of predicted sensor data values to becollected from the third computing device subsequent to the secondtarget action; retrieving, from the data repository, second analyticsdata based at least in part on the third characteristics data and athird target action of the plurality of target actions different fromthe second target action, wherein the second analytics data is a subsetof the outcome data stored in the data repository that corresponds to atleast a portion of the third characteristics data and the third targetaction; determining, based at least in part on the second analytics dataand the additional sensor data collected from the third computingdevice, (c) a predicted effectiveness value associated with the thirdtarget action for the additional sensor data and (d) an indication ofpredicted sensor data values to be collected from the third computingdevice subsequent to the third target action; generating one or both of(i) a first comparison of (a) the predicted effectiveness valueassociated with the second target action for the additional sensor dataand (c) the predicted effectiveness value associated with the thirdtarget action for the additional sensor data, or (ii) a secondcomparison of (b) the indication of predicted sensor data values to becollected from the third computing device subsequent to the secondtarget action and (d) the indication of predicted sensor data values tobe collected from the third computing device subsequent to the thirdtarget action; and outputting, via a user interface associated with thesecond computing device, a visualization of one or both of the firstcomparison or the second comparison.
 14. The non-transitorycomputer-readable medium of claim 13, wherein the first target action isidentical to the second target action.
 15. The non-transitorycomputer-readable medium of claim 13, wherein the first target action isdifferent from the second target action.
 16. The non-transitorycomputer-readable medium of claim 13, wherein the sensor data includesone or more of step count, step size, distance traveled, or flights ofstairs climbed.
 17. The non-transitory computer-readable medium of claim13, wherein the sensor data includes one or more of accelerometer data,gyroscope data, magnetometer data, or calorimeter data.
 18. Thenon-transitory computer-readable medium of claim 13, wherein theplurality of target action includes one or more of a surgicalintervention, a therapy, a drug, or a method.